iconview: Stop setting state flags on the style context for drawing

hsv: Stop setting state flags on the style context for drawing

expander: Use the widget state flags as a base for drawing

eventbox: Stop setting state flags on the style context for drawing

entry: Use the widget state flags as a base for drawing icons and text

entry: Stop setting state flags on the style context for drawing

combobox: Stop setting state flags on the style context for drawing

cellview: Stop checking for sensitivity on draw

This is needless since GtkCellRenderer does it consistently before rendering.

cellrenderertoggle: Use the cell renderer's state flags as a base for rendering

This allows us to pick the underlying widget's state flags that we don't
explicitly set here.

cellrenderer: Use the widget state flags as a base for cell renderers' state

checkmenuitem: Clean up state flags handling on drawing

checkbutton: Use the widget state flags as a base for drawing the indicator

Instead of building a set of state flags specifically for drawing the
indicator, base it on the underlying widget state flags.

checkbutton: Stop setting state flags on the style context for drawing

calendar: Use the widget state flags as a base for drawing arrows

This allows drawing calendar arrows in all possible states the main widget may
be in.

The arrow_state array is converted into a bit field since it only really needs
to store boolean information about prelight for each arrow.

calendar: Use the widget state flags as a base for drawing days

Instead of building a set of state flags specifically for drawing days, base
it on the underlying widget state flags.

button: Stop setting state flags on the style context for drawing

arrow: Stop setting state flags on the style context for drawing

accellabel: Stop setting state flags on the style context for drawing

widget: Set style flags on the style context when the flags are set

This will allow us to simplify most draw methods by not having to explicitly
set the style flags on the context.

widget: Always propagate state flags to all children

https://bugzilla.gnome.org/show_bug.cgi?id=666126

Updated POTFILES.in

bump glib depend to 2.31.6

GtkApplication: add menu API

We add the app-menu and menubar public APIs to GtkApplication while
leaving the implementation in GApplication.

The actual implementation will be moved soon.

missing file

GtkApplication: document relationship to gdkthreads

GtkApplicationWindow: deal with remote actions

Deal with remote action invocations correctly by implementing
GRemoteActionGroup in the same way that GApplication does and pushing
remote activations through the before/after_emit functions of the
GApplication associated with the window.

This is the last part of getting the threading situation right.

https://bugzilla.gnome.org/show_bug.cgi?id=665737

GtkApplication: lock gdk on incoming messages

When we have incoming activations or action invocations we should
acquire the GDK lock, just in case the program in question is using gdk
threads.

https://bugzilla.gnome.org/show_bug.cgi?id=665737

Move X property handling to GtkApplicationWindow

Don't try to deal with this using a qdata and signal connections in
GtkApplication.

Document that gtk_init is called without argv

This answers a question in bug 661823.

Fix a typo

Forgotten file

Show off some menus

Some more menu-related docs

Plugman: Find the plugins menu in a better way

Now that GtkBuilder finds named submenus, there's no need for
the clumsy menumodel navigation anymore.

GtkBuilder: pick up named submenus

When parsing GMenu xml, use the facility for pick up named submenus.
Note that <section id='foo'>...</section> is _not_ a named submenu.
It is a named item with an unnamed submenu :-(

Handle menu changes.

Add accelerators to bloatpad.

Refactor GMenuModel rendering for Mac OS.

gtkquartz-menu: fix some leaks

begin adding menu accelerators

Show accelerators in menus.

Two small fixes

Don't leak a session bus reference, and don't assume a display
is X11 just because we've built the X11 backend.

Fix up includes

bloatpad: add 'New Window' menu item

begin GtkApplication menu support for Mac OS

Another plugin, for good measure

Something for the eye

Add an action too

wip example for plugin/gmenu interaction

Update testgmenu to latest api changes

GtkApplicationWindow: share one GActionMuxer

Use the same GActionMuxer for menubars and accels instead of recreating
a new one each time.

Documentation additions

GtkApplicationWindow: Always install accelerators

We want accelerators to work, even if the menus are not shown
locally, so we can't rely on the GtkMenu code to set them up
for us. Currently, this code only installs accelerators when the
window is realized.

Bloatpad: Add an accelerator in the menu

GtkApplication: Extract accelerators from menus

This allows to specify accelerators in a convenient way, by
adding accel="..." attributes to the menu items in the
XML for the menu.

Currently, the accelerators are extracted only once, when the
menu property is changed on the application.

Introduce gtkaccelmapprivate.h

Move internal accel map API there and update all users.
Also, add an internal function to create an accel path for
an action and parameter, and use it in gtkapplication.c and
gtkmodelmenuitem.c instead of duplicating that code.

Bloatpad: Add an accelerator

GtkApplication: Add API to install accelerators for actions

GtkApplicationWindow: Set the accel group on constructed windows

This will make the menuitems pick up matching accel map entries
automatically. Currently, nothing creates such accel map entries,
though.

GtkApplicationWindow: Add a GtkAccelGroup

This will be used in the following patches.

Fix a gtk-doc warning

GtkApplication: export windows on the bus

And advertise their location on the bus using X11 properties.

(trivially) implement 'shutdown' in GtkApplication

Add an example

Update GtkApplicationWindow  docs

Whitespace fix

Make accelmap initialization more forgiving

Clean up includes

bloatpad: add proper sections to the menus

Split off GMenuModel -> GtkMenuBar code

Put this in a separate file and substantially refactor it.

Move handling of submenu creation into gtkmodelmenuitem where it
belongs.

Improve our handling of when to show separators or not.

Watch "shell shows menu" settings for changes

Correctly monitor the GtkSettings for changes to the
"gtk-shell-shows-app-menu" and "gtk-shell-shows-menubar" properties.

GtkSettings: quartz: shell always shows menus

Whitespace fixes

Never add separators to menubars

gmenu testcase: update to glib API changes

bloatpad: move action/menu setup to ::startup

No need to waste time doing this in init() if we are not going to become
the primary instance.

bloatpad: port to GActionMap for application

g_application_set_action_group() is now deprecated.

GtkModelMenuItem: don't leak a GVariant

bloatpad: use GtkBuilder for constructing menus

This is closer to what a real application would want to do.

GtkModelMenuItem: omit indicator if not required

GtkModelMenuItem, being based on GtkCheckMenuItem, was always reserving
space for a check/radio indicator.  This ends up looking pretty strange
in a GtkMenuBar.

Don't reserve space for the indicator unless it's appropriate.

GtkApplicationWindow: nuke some g_print spew

GtkApplcationWindow: plug two obvious leaks

GtkApplicationWindow: Consistently unparent menubar

We create it floating, and don't hold an extra ref, so we should
just unparent it.

GtkApplicationWindow: clean up menubar logic

Only add a separator when a section ends

introduce GtkModelMenuItem

This GtkMenuItem subclass (and GActionObserver implementation) contains
all the knowledge necessary for converting a GMenuModel item description
into a GtkMenuItem.

Remove much of the code that used to do this from
gtkapplicationwindow.c.

GtkSettings: add shell-shows-menubar property

Unity will set this to tell us that it is going to handle displaying the
menubar.

Only add separators when a section actually ends

Bloatpad: Add a View menu for fullscreen

Bloatpad: Don't leak a menu model

bloatpad: Be 640x480 by default

Because otherwise we're just a few pixels, and this is the least lame
solution I know of in GTK+.

GtkApplicationWindow: Further sanitize handling of merging app menu and menubar

The _set_show_app_menu should really be _set_show_menubar().

Also, correctly display just the window menu in the window when run
under GNOME 3.

bloatpad: Fix Edit to be a submenu

GtkApplication: Merge app menu and menubar

Change bloatpad to have both an app menu and a menubar.

GtkApplicationWindow: Make mnemonics work for stateful actions

Bloatpad: Add mnemonics to the menu

GtkApplicationWindow: Don't unref a NULL object

Adapt to changes in GLib API

g_application_get_menu() -> get_app_menu().

Drop GtkApplicationMenuButton for now

This feels premature; we do have the fallback situation covered
adaequately with the menubar, and people can do their own creative
solutions with gtk_application_window_get_menu(), so we don't have
to offer a widget for this right now.

Remove a redundant test

GtkApplicationMenuButton: add docs